Route Finding in Street Maps by Computers and People

We wrote a computer program which gives driving directions in northern New Jersey. Its data base combines a street map and a telephone book, so requests like “give directions from the Lackawanna Diner to the nearest dry cleaner’* (properly specified) can be answered. This problem involves both human factors and algorithmic problems. From the human factors standpoint, what kind of route is best: shortest distance, most concise directions, fewest turns, or some combination of these? And from the algorithmic standard, what is a good shortest-path algorithm: breadth-first search, depth-first search, pre-storing important routes, divide and conquer, or keep a hierarchy of maps with progressively fewer streets? We implemented breadth-first and depth-first search both single-ended and double-ended. Double-ended search was faster in 14 of 16 examples and produced shorter or equal length routes in 13 of 16. Depth-first search was always faster than breadth-first, and produced shorter routes half the time. We also asked eight subjects for directions on 4 maps. The 32 tries at 4 problems produced 22 different routes. People’s strategies typically include finding main roads, and applying divide-andconquer as well as depth-first search. But it is difficult to characterize the experimental subjects, since different problems caused them to try different search algorithms. Figure 1. Downtown Chatham, NJ Introduction. British studies show that 4% of all driving is wasted, done by people who are either completely lost or just not following the best r0ute.l Experimentation with routefinding is both a practical and an interesting heuristic problem. We have a street map of Morris and Essex counties in New Jersey,2 a telephone book covering parts of the area, and a program to give driving directions. A sample map of Chatham, NJ is shown in Figure I; a map of part of Madison, NJ including some business names is shown in Figure 2. We can find routes between two places where the starting place is identified as: (a) a street number and name; (b) the intersection of two streets; or (c) the name of a business listed in our Yellow Pages with an identifiable address; and the ending place is identified in any of these ways or as (d) “nearest X” where X is the name of a Yellow Pages category. Directions can be printed, or a map showing the route drawn. The large and accurate data base eliminates the need to handle “fuzzy” positions as considered by McDermott3 but instead forces us to worry about the implementation of the routefinder. At first, we actually found the shortest route. However, people shown minimum-distance routes often recoiled in horror; they had far too many turns. In our area, on a trip of any length, the program would usually make turns at least every mile, having found some way to save a few yards. We introduced a criterion that each right turn cost l/8 mile and each left turn cost 114 mile. With these extra penalties, minimum-distance routes look reasonable to users. Figure 2. Downtown Madison, NJ 258 From: AAAI-82 Proceedings. Copyright ©1982, AAAI (www.aaai.org). All rights reserved. Some sample routes, with drawn maps, are shown in Figures 3 and 4. In Figure 4, note that the program has gone an extra block NW on South Street in order to avoid making the double turn on Maple St, which saves less than the 3/8 mile it would be charged. In addition to handling distance minimization, the program also has facilities for handling one-way streets and limited access highways. We are currently extending the cost algorithm to include assumption of different rates of speed on different streets. Computer algorithms. Mathematically, this problem is familiar as the shortest-path prob]ems4,5v6J+8,9 1 n the substantial literature, a nondirectional breadth-first search is normally recommended. The reason is that most of the mathematicians are trying to minimize the worst-case time, and the worst case includes non-planar graphs with short edges between random points in the graph. In such a case, there is not much advantage to “directional” searching, even when directions can be defined. Furthermore, many of the graphs being used in these papers have few nodes and many edges. Our graphs, however, are quite different. Street maps are nearly always planar (some parts of San Francisco being exceptions), and have Euclidean distances and other nice properties like triangle inequalities. More important, there are a great many nodes while edges are sparse. In our Morris and Essex street map, there are 40,000 nodes and 65,000 edges; of these 39,000 nodes and 51,000 edges involve streets (rather than rivers, town boundaries, railroads and the like). (To compare with something more familiar to people, Manhattan has 5000 nodes and 8000 edges; 4000 nodes and 7000 edges involve streets.) As a result, algorithms which touch almost every street node are too slow in our case. Even considering all the street nodes that lie in between the source and destination would prevent rapid response. (Although we retain the railroad and river information so that important landmarks are presented in directions or on drawn maps, they are not searched in route-finding). We have compared the basic breadth-first and depth-first search algorithms, using both double-ended and single-ended searching. In breadth-first search, we do not spread out omnidirectionally; instead the search is biased in the right direction by penalizing points based on their distance from the destination. In depth-first search. we follow streets as long as the distance on this street is decreasing. The single-ended searches go from the starting point to the destination; the double-ended searches advance from both points until a meeting point in the middle is found. Table 1 shows the rough results, averaged over ten trips in New Jersey and California. Table 1.